home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1277.txt < prev    next >
Text File  |  1994-08-01  |  22KB  |  686 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                            S.E. Hardcastle-Kille
  8. Requests for Comments 1277                   University College London
  9.                                                          November 1991
  10.  
  11.  
  12.                       Encoding Network Addresses
  13.             to support operation over non-OSI lower layers
  14.  
  15.  
  16.  
  17.  
  18. Status of this Memo
  19.     This RFC specifies an IAB standards track protocol for the
  20.     Internet community, and requests discussion and suggestions for
  21.     improvements.  Please refer to the current edition of the ``IAB
  22.     Official Protocol Standards'' for the standardization state and
  23.     status of this protocol.  Distribution of this memo is unlimited.
  24. Abstract
  25.  
  26.     The OSI Directory specifies an encoding of Presentation Address,
  27.     which utilises OSI Network Addresses as defined in the OSI
  28.     Network Layer standards [CCI88] [ISO87a].  The OSI Directory, and
  29.     any OSI application utilising the OSI Directory must be able use
  30.     these Network Addresses to identify end systems.  Currently, OSI
  31.     applications are often run over lower layers other than the OSI
  32.     Network Service.  It is neither reasonable nor desirable for
  33.     groups wishing to investigate and use OSI Applications in
  34.     conjunction with the OSI Directory to be dependent on a global
  35.     OSI Network Service.  This document defines a new network address
  36.     format, and rules for using some existing network address
  37.     formats.  The scope of this document is:
  38.  
  39. 1.  Any TCP/IP network supporting COTS using RFC 1006.
  40.  
  41. 2.  Any mapping of COTS onto X.25 (usually X.25(80)), where X.25 is
  42.     not used to provide CONS (i.e., only DTE and not Network address
  43.     is carried).
  44.  
  45.  
  46.     The approach could also be extended to use with other means of
  47.     providing COTS (or CLTS). It is not appropriate for use where
  48.     CONS or CLNS is used to provide COTS (or CLTS).
  49.  
  50.  
  51.  
  52.  
  53. RFC 1277           Encoding Network Addresses            November 1991
  54.  
  55.  
  56. 1  Introduction
  57.  
  58. The OSI Directory specifies an encoding of Presentation Address, which
  59. utilises OSI Network Addresses as defined in the OSI Network Layer
  60. standards [CCI88] [ISO87a].  The OSI Directory, and any OSI
  61. application utilising the OSI Directory must be able use these Network
  62. Addresses to identify end systems.
  63. Currently, OSI applications are often run over lower layers other than
  64. the OSI Network Service.  It is neither reasonable nor desirable for
  65. groups wishing to investigate and use OSI Applications in conjunction
  66. with the OSI Directory to be dependent on a global OSI Network
  67. Service.  This RFCdefines mechanisms to encode addressing information
  68. within Network Addresses, in order to support this type of working.
  69. In particular, support is defined for RFC 1006 mapping of COTS onto
  70. TCP/IP and COTS mapped onto X.25(1980) [RC87, CCI80].
  71.  
  72. Where an OSI application is run over CLNS on the internet, the NSAP
  73. Guidelines of RFC 1237 should be followed [CGC91].
  74. This document must be read in the context of ISO 8348 Addendum 2
  75. [ISO87b].  It will not be meaningful on its own.
  76.  
  77.  
  78. 1.1  Historical Note
  79.  
  80. This document was originally published as UCL Research Note RN/89/13
  81. and as a project THORN internal document [Kil89].  It was devised in
  82. response to two projects which faced this requirement, and was agreed
  83. as a common approach.  The projects were:
  84.  
  85.  
  86.  o  The THORN project, which is an Esprit Project building an OSI
  87.     Directory [SA88].
  88.  
  89.  o  The ISODE project [Ros90], and in particular the QUIPU directory
  90.     being developed at UCL [Kil88].
  91.  
  92. The proposal has been implemented, and the viability of the solution
  93. demonstrated.
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101. Hardcastle-Kille                                                Page 1
  102.  
  103.  
  104.  
  105.  
  106. RFC 1277           Encoding Network Addresses            November 1991
  107.  
  108.  
  109. 2  Problem Statement
  110.  
  111. When utilising the OSI Directory, the OSI location of an End System
  112. will be determined by a Network Address, which is taken from a
  113. Presentation Address, looked up in the OSI Directory.
  114. OSI applications are currently operated over the following lower
  115. layers.
  116.  
  117.  
  118.  o  An international X.25 network, which routes on the basis of X.121
  119.     addresses.  By and large this is X.25(80), but some parts are now
  120.     X.25(84) and will carry Network Addresses as user data.  OSI
  121.     Transport is mapped onto the variant of X.25 which is available.
  122.  
  123.  o  Large private X.25 networks, which do not have DNICs, but are
  124.     otherwise similar to the previous (in particular Janet).
  125.  
  126.  o  Isolated networks running Connection Oriented Network Service
  127.     (e.g., Pink Book Ethernets).
  128.  
  129.  o  Isolated networks running Connectionless Network Service (e.g.,
  130.     MAP LANs).
  131.  
  132.  o  The Connectionless Network Service Protocol (CLNP) pilot,
  133.     currently taking place in the NSFNet and NORDUNet communities.
  134.  
  135.  o  Isolated TCP/IP LANs, utilising RFC 1006 to support the OSI
  136.     Transport Service[RC87].
  137.  
  138.  o  The DARPA/NSF Internet, using RFC 1006.
  139.  
  140. In general, these systems need to be interconnected by the use of
  141. transport bridging or application relaying.  Operation of transport
  142. bridges causes a number of problems which it is desirable to avoid.
  143. Only some applications can support relaying, and this is not always
  144. satisfactory.
  145.  
  146.  
  147. 2.1  The ``Right Solution''
  148.  
  149. It is worth noting briefly what the intended (OSI) solution is.  There
  150. is a single global network service.  Network Addresses are globally
  151. allocated, and do not imply anything about routing or location.  An
  152.  
  153.  
  154. Hardcastle-Kille                                                Page 2
  155.  
  156.  
  157.  
  158.  
  159. RFC 1277           Encoding Network Addresses            November 1991
  160.  
  161.  
  162. End System is attached to one or more subnetworks at Subnetwork Points
  163. of Attachment (SNPAs).  Intermediate Systems join subnetworks, again
  164. being attached at SNPAs.  Routing is achieved by repeated binding of
  165. Network Address to SNPA (initially at the Originating End System, and
  166. then at each Intermediate System).  This binding is achieved by
  167. network level routing mechanisms.
  168. This can only work in a pure OSI environment with a single ubiquitous
  169. network service (either connectionless or connection-oriented), and so
  170. is not sufficient for the problem being addressed by this note.
  171.  
  172.  
  173. 2.2  General Approach
  174.  
  175. This section describes the use of network addresses, and gives a
  176. functional overview of the problem being takceled.  The means of
  177. connecting to a remote Application Entity is broadly as follows.
  178.  
  179. 1.  Look up the Application Entity in the OSI Directory to obtain the
  180.     Presentation Address 1.
  181.  
  182. 2.  Extract each Network Address from the Presentation Address, and
  183.     determine if it can be used (and how).
  184.  
  185. 3.  Determine an order of preference for the Network Addresses.
  186.  
  187. 4.  Attempt to connect to one or more of the Network Addresses.
  188.  
  189.  
  190. This note is concerned with the second step, and will probably have
  191. implications on the third.  There is currently no directory service to
  192. provide step 2, and so this (interim) approach must be algorithmic.
  193. All addressing information required for the network must be extracted
  194. from the network address.
  195. This note describes the use of Network Addresses for networks which do
  196. not provide the OSI Network Service (CLNS or CONS), and places
  197. constraints on the use of X.121 form network addresses when used for
  198. an OSI Network Service.  The following types of Network Address are
  199. discussed in this note:
  200.  
  201. ----------------------------
  202.     1. Strictly an Application Entity should have only one
  203. Presentation Address.  In practice it may have several, and the
  204. network addresses of each Presentation Address should be considered.
  205.  
  206.  
  207. Hardcastle-Kille                                                Page 3
  208.  
  209.  
  210.  
  211.  
  212. RFC 1277           Encoding Network Addresses            November 1991
  213.  
  214.  
  215.  o  Use of X.121 form Network Addresses.
  216.  
  217.  o  A special encoding of Telex form Network Addresses.
  218.  
  219.  
  220. 3  Network addresses with X.121 AFI
  221.  
  222. This note defines an approach for use of network addresses with the
  223. X.121 AFI.
  224. The IDP of network addresses is used to allow worldwide administration
  225. of the NSAP address space.  As such, not all values of the IDP will in
  226. practice have topological significance (which implies that in some
  227. cases the IDP will not be sufficient for network layer routing).
  228. However, it is recommended that any End System using the Connection
  229. Oriented Network Service and with access to the international X.25
  230. service uses the X.121 form of NSAP address relative to its access
  231. point.  This allows routing across the worldwide X.25 based public
  232. data networks to be based on the X.121 addresses.  Allocation of DSP
  233. (Domain Specific Part) within this form of address is a private issue.
  234.  
  235. The IDP is primarily an allocation mechanism, and the user (end
  236. system) cannot in principle assume any implied routing.  However, due
  237. to the lack of a network directory service, it is recommended that any
  238. End System with Connection Oriented Network Service and access to the
  239. international X.25 service uses X.121 form relative to its access
  240. point.  Allocation of DSP (Domain Specific Part) is a private issue.
  241. Conversely it is recommended that if an X.121 IDP (Initial Domain
  242. Part) form Network Address is interpreted, then the X.121 address will
  243. provide a route (by defining an SNPA on the international X.25
  244. network).  There may be additional and perhaps preferable routes which
  245. can be determined by private means.
  246. If the DSP is absent, the form should be interpreted as implying a
  247. mapping of Transport onto X.25(80).
  248.  
  249.  
  250. 4  New Network Address Format
  251.  
  252.  
  253. This section defines a new network address format.  The scope of this
  254. format is currently:
  255.  
  256. 1.  Any TCP/IP network supporting COTS using RFC 1006.
  257.  
  258.  
  259.  
  260. Hardcastle-Kille                                                Page 4
  261.  
  262.  
  263.  
  264.  
  265. RFC 1277           Encoding Network Addresses            November 1991
  266.  
  267.  
  268. 2.  Any mapping of COTS onto X.25 (usually X.25(80)), where X.25 is
  269.     not used to provide CONS (i.e., only DTE and not Network address
  270.     is carried), except where the international X.25 service is used
  271.     and no PID or CUDF is required.
  272.     These exceptions are the cases which are handled by use of X.121
  273.     AFI (Section 3).  The intention is to use the X.121 AFI wherever
  274.     possible, and the formats defined in this section are for the
  275.     remaining cases.
  276.  
  277. The approach could also be extended to use with other means of
  278. providing COTS (or CLTS). It is not appropriate for use where CONS or
  279. CLNS is used to provide COTS (or CLTS).
  280.  
  281.  
  282. 4.1  Requirements
  283.  
  284. The requirements for use of OSI over existing networks not supporting
  285. CONS or CLNS, when using the OSI Directory are:
  286.  
  287.  
  288. 1.  The information for the layers below Transport must be obtained
  289.     from the Network Address.  This is essential, because we wish to
  290.     use the OSI Directory in a standard manner, and the Network
  291.     Address is the information available.
  292.  
  293. 2.  The Network Addresses must be globally unique, as they can be
  294.     looked up by anyone with access to the Directory.
  295.  
  296. 3.  The Network Address should be allocated so that confusion with a
  297.     ``real'' Network Address (i.e., one which defines an NSAP using
  298.     CONS or CLNS as opposed to X.25(80) or RFC 1006) is unlikely.
  299.  
  300. 4.  Network Addresses must be interpretable on the basis of a well
  301.     known information, or on information which can be obtained from
  302.     the (application level) OSI Directory.  (This RFConly uses well
  303.     known information).
  304.  
  305. 5.  The identity of the network in question must be deducible from the
  306.     Network Address
  307.  
  308. 6.  All network specific addressing information (including the SNPA)
  309.     must be deducible from the Network Address
  310.  
  311.  
  312.  
  313. Hardcastle-Kille                                                Page 5
  314.  
  315.  
  316.  
  317.  
  318. RFC 1277           Encoding Network Addresses            November 1991
  319.  
  320.  
  321. 4.2  IDP Choice
  322.  
  323. The IDP is used with Telex AFI. The Telex AFI is used because:
  324.  
  325.  o  It gives the largest DSP
  326.  
  327.  o  It is less likely than other forms to be used for ``real'' Network
  328.     Addresses
  329.  
  330.  
  331. The following AFIs might have been chosen, but are not used for the
  332. reasons given:
  333.  
  334.  o  Local (the values must be globally unique)
  335.  
  336.  o  X.121 (because it may be confused with other uses of OSI network
  337.     addresses)
  338.  
  339.  o  DCC and ICD (because it may be confused with other uses of OSI
  340.     network addresses)
  341.  
  342. The IDI should be assigned in a manner appropriate to the use of the
  343. encoding.  For example, for operation on a private network within an
  344. organisation, the telex number of that organisation would be a good
  345. choice.  Some well known networks are given assignments in Appendix A.
  346.  
  347.  
  348. 4.3  The DSP Encoding
  349.  
  350. The network address is used as follows.
  351.  
  352.  
  353.  o  A (sub)network is identified by the IDP and a small part of the
  354.     DSP.
  355.  
  356.  o  The remainder of the DSP encodes network specific information
  357.  
  358. The DSP format is now defined.  The top level format is independent of
  359. the means used to provde COTS. Two formats for the remainder of the
  360. DSP are then defined, for specific means of providing COTS.
  361.  
  362. A decimal abstract encoding is defined for the DSP. The ECMA 117
  363. format might have been used, but it is not suitable.  [TC386].  Use of
  364. a binary encoding, with the DSP structured in ASN.1 would have been a
  365.  
  366. Hardcastle-Kille                                                Page 6
  367.  
  368.  
  369.  
  370.  
  371. RFC 1277           Encoding Network Addresses            November 1991
  372.  
  373.  
  374. very attractive approach.  However, there is insufficient space in the
  375. Network Address for this to be feasible.
  376. The following structure is defined:
  377.  
  378.                  ____________________________________
  379.                  |_Digit___||1-2__|______3-27_______|_
  380.                  |_Meaning_||PrefixN|etwork_Specific_|
  381.  
  382. 2 digits Prefix.  This allows for multiple usage of the same DSP, by
  383.     not consuming it all.  It also allows for the DSP to be used with
  384.     different encodings.
  385.  
  386. Network Specific The network specific allocation should be less than
  387.     20 digits if this DSP structure is to be used with any IDI format.
  388.     This is increased to 27 for the Telex format.
  389.  
  390.  
  391. The IDP + 2 digit prefix identify a subnetwork in which the value of
  392. the remainder of the DSP (Network Specific Part) is to be interpreted.
  393.  
  394. 4.4  X.25(80) Network Specific Format
  395.  
  396. The IDP/Prefix identifies an X.25(80) subnetwork.  There is a need to
  397. represent a DTE Number, and optionally an X.25 Protocol ID or CUDF
  398. (many implementations require these due to shortage of X.121 address
  399. space) in the DSP. This is structured in one of two possible ways:
  400.  
  401.                        ________________________
  402.                        |_Digit___||1R|emainder_|
  403.                        |_Meaning_||0_|_DTE____|_
  404.  
  405.      ____________________________________________________________
  406.      |_Digit___||_1___|_______2________|3_--_(n*3)+2_|Remainder_|_
  407.      |_Meaning_||Type__|PID/CUDF_Length_|_PID/CUDF___|___DTE____|_
  408.      |_Values__||1_or_2_|_____n________|_____________|__________|_
  409.  
  410. The network specific part is structured as follows:
  411.  
  412.  
  413. Type This has the following values
  414.  
  415.     0 DTE only
  416.  
  417.     1 DTE + PID
  418.  
  419. Hardcastle-Kille                                                Page 7
  420.  
  421.  
  422.  
  423.  
  424. RFC 1277           Encoding Network Addresses            November 1991
  425.  
  426.  
  427.     2 DTE + CUDF
  428.  
  429.     3-9 Reserved
  430.  
  431. PID/CUDF Length The length of the PID/CUDF in octets
  432.  
  433. PID/CUDF The PID/CUDF takes as many digits as indicated by 3 times
  434.     octet 2.  Each octet of the PID/CUDF is encoded as three decimal
  435.     digits, representing the decimal value of the octet.
  436.  
  437. DTE The DTE is terminated by the end of the Network Address.
  438.  
  439.  
  440.  
  441. For example, the JANET DTE 000005111600 with ASCII CUDF ``12'' would
  442. be encoded in the following way.  The first lines describe the
  443. abstract notation.  Note that where the IDI is not of maximum length,
  444. that the translation to concrete decimal is not mechanical
  445.  
  446.  
  447. _______________________________________________________________________________
  448. |Part___|_|_____IDP_________|_______________________DSP_______________________|_
  449. |Comp___|_|AFI__|___IDI_____|Prefix_|Dte+Cudf_|Len|________CUDF_+_DTE_________|_
  450. |Octet__|_|____|____________|_1-2___|___3_____|_4_|___________5-20____________|_
  451. |Value__|T|elex_|007_28722__|__02___|___2_____|_2_|____049050_000005111600____|__
  452. |Ct_Dec_|_|54___|007_28722__|__02___|___2_____|_2_|____049050_000005111600____|_
  453. |Ct_Bin_|_|54___|00_72_87_22_|_02___|_____22______|04_90_50_00_00_51_11_60_0f_|_
  454.  
  455. Note that concrete binary is representing octets in hexadecimal.  This
  456. is the syntax most likely to be used in practice.  The CUDF is
  457. represented by two octets 049 and 050 (decimal), which map to six
  458. digits.
  459.  
  460.  
  461. 4.5  TCP/IP (RFC 1006) Network Specific Format
  462.  
  463. The IDP and 2 digit prefix identifies a TCP/IP network where RFC 1006
  464. is applied.  It is necessary to use an IP Address, as there are
  465. insufficient bits to fit in a domain.  It is structured as follows:
  466.  
  467.       __________________________________________________________
  468.       |_Digit___||_1-12____|13-17_(optional)_|18-22_(optional)_|_
  469.       |_Meaning_||IP_Address_|____port_______|__Transport_Set__|_
  470.  
  471.  
  472. Hardcastle-Kille                                                Page 8
  473.  
  474.  
  475.  
  476.  
  477. RFC 1277           Encoding Network Addresses            November 1991
  478.  
  479.  
  480. For TCP/IP there shall be a 20 digit long network-specific part.
  481. First 12 digits are for the IP address.  The port number can be up to
  482. 65535, and needs 5 digits (this is optional, and is defaulted as
  483. defined in RFC 1006).  Finally, there is a third part to the address,
  484. which is defined here as ``transport set'' that indicates what kind of
  485. IP-based transport protocols is used.  This is a decimal number from
  486. 0-65535 which is really a 16-bit flag word.  1 is TCP, 2 is UDP.
  487. Further values of this code are assigned by the IANA. If the transport
  488. set is not there or no bits are set, it means ``default'' which is
  489. TCP. This is encoded in 5 digits.
  490. For example, the IP Address 10.0.0.6 with port 9 over UDP is encoded
  491. as:
  492.  
  493.  
  494. ____________________________________________________________________________
  495. |Part______|_|_____IDP_________|____________________DSP____________________|_
  496. |Component_|_|AFI__|___IDI_____|Prefix_|___IP_Address_____|_Port__|_T_Set__|_
  497. |Octet_____|_|____|____________|_1-2___|______3-14________|_15-19_|_20-24__|_
  498. |Value_____|T|elex_|007_28722__|__03___|_010_000_000_006__|_00009_|_00002__|__
  499. |Cncrt_Dec_|_|54___|007_28722__|__03___|_010_000_000_006__|_00009_|_00002__|_
  500. |Cncrt_Bin_|_|54___|00_72_87_22_|_03___|01_00_00_00_00_06_|00_00_9|0_00_02_|_
  501.  
  502. 5  Encoding
  503.  
  504.  
  505. This document describes allocation of Network Addresses, with the DSP
  506. considered in Abstract Decimal.  The encoding of this for use in
  507. protocols (typically as Concrete Binary) is described in ISO 8348
  508. Addendum 2 [ISO87a].
  509.  
  510.  
  511. 6  References
  512.  
  513. References
  514.  
  515. [CCI80]  CCITT. Recommendation X.25, interface between DTE and DCE
  516.          for packet mode terminals, 1980.
  517.  
  518. [CCI88]  The Directory --- overview of concepts, models and services,
  519.          December 1988. CCITT X.500 Series Recommendations.
  520.  
  521. [CGC91]  R. Colella, E. Gardner, and R. Callon.  Guidelines for OSI
  522.          NSAP Allocation in the Internet. Request for Comments 1237,
  523.  
  524.  
  525. Hardcastle-Kille                                                Page 9
  526.  
  527.  
  528.  
  529.  
  530. RFC 1277           Encoding Network Addresses            November 1991
  531.  
  532.  
  533.          NIST, July 1991.
  534.  
  535. [ISO87a] Information processing systems - data communications -
  536.          network services definition:  Addendum 2 - network layer
  537.          addressing, March 1987. ISO TC 97/SC 6.
  538.  
  539. [ISO87b] ISO DIS 7498-3 on naming and addressing, May 1987.
  540.          ISO/IEC/JTC-1/SC 21.
  541.  
  542. [Kil88]  S.E. Kille. The QUIPU directory service.  In IFIP WG 6.5
  543.          Conference on Message Handling Systems and Distributed
  544.          Applications, pages 173--186. North Holland Publishing,
  545.          October 1988.
  546.  
  547. [Kil89]  S.E. Kille. An interim approach to use of network addresses.
  548.          Research Note RN/89/13, Department of Computer Science,
  549.          University College London, February 1989.
  550.  
  551. [RC87]   Marshall T. Rose and Dwight E. Cass. ISO Transport Services
  552.          on top of the TCP. Request for Comments 1006, Northrop
  553.          Corporation Technology Center, May 1987.
  554.  
  555. [Ros90]  M.T. Rose. The ISO development environment:  User's manual
  556.          (version 6.0), January 1990.
  557.  
  558. [SA88]   F. Sirovich and M. Antonellini. The THORN X.500 distributed
  559.          directory environment. In Esprit Conference Week, November
  560.          1988.
  561.  
  562. [TC386]  ECMA TC32. Domain specific part of network layer addresses.
  563.          ECMA Standard 117, ECMA, June 1986.
  564.  
  565.  
  566. 7  Security Considerations
  567.  
  568. Security considerations are not discussed in this memo.
  569.  
  570.  
  571. 8  Author's Address
  572.  
  573.     Steve Hardcastle-Kille
  574.     Department of Computer Science
  575.     University College London
  576.  
  577.  
  578. Hardcastle-Kille                                               Page 10
  579.  
  580.  
  581.  
  582.  
  583. RFC 1277           Encoding Network Addresses            November 1991
  584.  
  585.  
  586.     Gower Street
  587.     WC1E 6BT
  588.     England
  589.  
  590.     Phone:  +44-71-380-7294
  591.  
  592.  
  593.     EMail:  S.Kille@CS.UCL.AC.UK
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.  
  621.  
  622.  
  623.  
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631. Hardcastle-Kille                                               Page 11
  632.  
  633.  
  634.  
  635.  
  636. RFC 1277           Encoding Network Addresses            November 1991
  637.  
  638.  
  639. A  Allocations for well known networks
  640.  
  641. A.1  Values
  642.  
  643.  
  644. This appendix gives an allocation for three well known networks.  All
  645. are allocated on the basis of the supposed Telex number 00728722.
  646. This number is being used in pilot operations, and so is retained
  647. here.
  648.                _______________________________________
  649.                |_________Net__________Telex____Prefix_|
  650.                | International X.25 |007 28722 01     |
  651.                | Janet              |007 28722 02     |
  652.                | Darpa/NSF Internet |007 28722 03     |
  653.                |_IXI________________|007_28722_06_____|
  654.  
  655. The international X.25 allocation is only used where a CUDF or PID is
  656. needed.  In other cases, an X.121 form Network Address with no DSP
  657. should be used.
  658.  
  659.  
  660. A.2  Delegation
  661.  
  662. The values assigned in this document are now in widespread use.  As
  663. the number is arbitrary, it would be undesirable to change the numbers
  664. without a sound technical reason.  However, it is important to
  665. guarantee that the numbers are stable.
  666.  
  667. This Internet Draft commits UCL not to reassign the portions of the
  668. number space allocated here.
  669. The DARPA/NSF Internet space (Prefix 03) is delegated to the IANA.
  670.  
  671.  
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683.  
  684. Hardcastle-Kille                                               Page 12
  685.  
  686.